Communications networks, such as the Internet or intranets, connect hosts that may communicate via the network. Such networks often use the Internet Protocol (IP) by which a communication, e.g. a message, file or other data unit, is sent between host computers, each having at least one unique IP address that includes an identification of a network and an identification of the host on that network. Gateways or routers (collectively “routers”) route the communication to the intended destination address. The IP routing protocol requires a complementary communications protocol to enable communications between hosts on a network.
The Transmission Control Protocol (TCP) is one such complementary communications protocol. In a TCP environment, a sender's TCP program layer divides a message/file into numbered packets (data units) and passes them to the IP program layer. TCP is a highly reliable delivery protocol.
The User Datagram Protocol (“UDP”) is an alternative complementary communications protocol. Unlike TCP, UDP does not divide a message into packets, reassemble packets, or track packet sequence. Rather, UDP treats each datagram (data unit) as a whole message.
TCP is suitable for unicast (point-to-point) communications sent from a single sender to a single recipient. However, TCP is unsuitable for multi-recipient (point-to-multipoint) communications that are sent from a single sender to multiple recipients using an address that refers to multiple hosts on a network and causes delivery of the communication to each of the those hosts. Multi-recipient communications include broadcast and multicast communications. Various multicast techniques exist, including hardware-based multicast and IP-based multicast. Both multicasting techniques use a communication's destination address to specify multicast delivery. UDP uses “best effort” delivery methods and therefore is not as reliable as TCP. However, this makes UDP ideal for use with multi-recipient communications. UDP is often used in corporate networks for multi-recipient communications or other applications in which highly reliable delivery is inefficient or unnecessary.
FIG. 1 illustrates an example in which a single network is divided into a group of subnetworks by allowing a single network address to span multiple physical subnetworks. This is common in corporate intranets and allows for hierarchical routing of communications. In the example of FIG. 1, a corporation has a single network address of 128.10.0.0 to which communications may be sent for unicast delivery to hosts within network 10. The network 10 includes two subnetworks 11, 12 having addresses 128.10.1.0 and 128.10.2.0 respectively. For example, 128.10.1.0 may correspond to a company's subnetwork in the U.S. and 128.10.2.0 may correspond to the company's subnetwork in Japan. A gateway or router 20 is connected to the Internet 22 and is capable of making routing decisions to hosts, e.g. 14, 15, 16, 17, 18, 19, based on the third octet of the destination IP address of a given communication.
Known multi-recipient techniques may be used for delivery within a single multi-recipient domain, which often corresponds to a single network or subnetwork. This is inherent to the hierarchical nature of the IP addressing scheme. In the example of FIG. 1, a multicast message may be sent to all hosts 14, 15 in the U.S. subnetwork 11, or to all hosts 16, 17 in the Japanese subnetwork 12.
However, known multi-recipient techniques are inadequate for selective multi-recipient delivery across multiple domains, e.g. a single multicast to hosts 14, 15, 16, 17 within both the Japanese and U.S. subnetworks 11, 12. For example, due to limitations typically imposed on time-to-live (TTL) and/or the maximum number of hops for a multicast (typically 1), a multicast message would not be deliverable from the US to Japan. Such limitations are imposed to limit the amount of network utilization and prevent network congestion, i.e. to prevent unintended massive broadcast/multicast.
A broadcasting technique may allow delivery across multiple multicast domains where such limits are not exceeded, but not without hitting additional subnetworks and therefore sending the message to unintended recipients. For example, consider that the network 10 in the example of FIG. 1 also includes a third subnetwork 13 including hosts 18 and 19. Using standard broadcasting techniques, a single communication may be easily delivered to all hosts within a single network, e.g. 128.10.0.0, or to all hosts within a single subnet stemming from address 128.10.0.0. However, such techniques are inadequate for selective targeting of messages across domains, e.g. for broadcasting to fewer than all subnets of a network or between subnets of different networks, there being no relationship of IP addresses that may be interpreted by standard multicast techniques to provide a targeted multicast message.
Known multi-recipient techniques are unsatisfactory for sending a single, targeted multi-recipient communication to hosts within subnet 128.10.1.0 and 128.10.2.0 without also delivering the communication to all hosts in subnet 128.10.3.0. Within a single company, this may unnecessarily congest networks. For example, a communication relating to a departmental lunch meeting in Japan would be broadcast to all hosts in US and Japan. Across networks or subnetworks of different companies it may be extremely undesirable as many unintended recipients could receive the message, including those outside of the sender's or recipient's company or entity.
IP tunneling combines unicast and multi-recipient delivery, and may combine TCP and UDP techniques. IP tunneling is known for use in the multicast context. Such tunneling refers to the encapsulation of multicast packets in an IP datagram (i.e. unicast packet) to route through parts of a network that don't support multicast routing. The encapsulation is added on entry to a tunnel and stripped off on exit from a tunnel. More specifically, the packet is wrapped, sent through a unicast tunnel, unwrapped, and then resent in the destination subnet.
However, IP tunneling as known in the art is not “intelligent.” The packet is simply transmitted in the destination subnet in the form, or substantially the form, in which is was sent. There is no intelligent customization or configuration of the packet for the destination network. This is due in part to the lack of knowledge at the sender of routing and other information specific to the destination subnetwork. Accordingly, there are limits inherent to tunneling, including that the packets are subject to restrictions from the origin network. For example, when a multicast packet is sent with a TTL of 1, as is often the case, the TTL is decremented to 0 upon receipt at a recipient in the origin network and therefore is not forwardable or receivable in the destination network because the TTL of 0 prevents any additional hops. Additionally, the packet may not be properly configured to specify port numbers, multicast addresses, etc. specific to the destination network. For example, the packet may be configured for multicast on address X in the origin network but all hosts in the destination network are configured to listen for multicast on address Y. Furthermore, IP tunneling involves point-to-point communication, and not point-to-multipoint/multi-subnetwork communication.